Sommaire

Liste des projets

Voici quelques-uns des projets les plus captivants sur lesquels j'ai travaillé: ils sont anonymisés et épurés des informations. Faites défiler ou cliquez sur les titres ci-dessous pour en savoir plus !

Mémoire de recherche

Dans le cadre de mes études, j'ai du faire des recherches et rédiger un mémoire. J'ai décidé d'utiliser une problématique que j'avais à traiter au travail : les migrations AWS EC2. Plus précisément, comment passer du type d'instance Para-Virtualized (PV) au type Hardware-Virtual-Machine (HVM).
Ce type de migration n'est pas supporté nativement par AWS et pour de bonnes raisons. Cependant avec une bonne compréhension des mécanismes de virtualisation, des anneaux CPU, de la gestion des instructions des invités et des systèmes d'exploitation, il peut être possible d'effectuer la migration.

Mémoire de recherche - Migration AWS EC2 de PV vers HVM

Projets

Amazon Web Service (AWS) - Automatisation d'une infrastructure

Mots-clés : CloudFormation - Serverless - Stacks/Templates - Scripts PowershellCadre : Travail

Automatisation du déploiement d'une infrastructure AWS de plus de 100 composants à l'aide de AWS CloudFormation/Serverless. L'automatisation facilite la création de nouveaux environnements (développement, test...) de manière fiable et rapide.

Automatisation complète du déploiement du site web d'un des plus grands vendeurs mondiaux de magazines et journaux en ligne. L'infrastructure est assez complexe, elle combine une partie statique (navigation) et une partie dynamique (panier). Le déploiement supporte de nombreux cycles de vie/stage : PROD, DEV, TEST, UAT avec chacun leurs spécificités. D'autres cycles de vie peuvent facilement être ajoutés.

Le site statique repose sur une régénération plusieurs fois par jour. Le site dynamique repose sur plusieurs fonctions "serverless". Des bases de données SQL et no-SQL sont utilisées, ainsi que de nombreux autres services, tels que des éléments réseau, des files d'attente de messages, des fonctions "at edge"... Globalement, c'est une infrastructure de plus de 100 composants AWS interconnectés qui avait besoin d'être automatisée.

Pour ce faire, j'ai utilisé Serverless Framework (SLS) qui est indépendant du fournisseur cloud utilisé: il fonctionne donc comme une surcouche pour AWS CloudFormation. SLS fournit plus de fonctionnalités via des appels AWS CLI/SDK transparents. Par exemple, les références de variables "cross-region cross-stack" SLS se sont avérées très pratiques car AWS CloudFormation ne prend en charge le "cross-stack" que dans la même région. Des plugins communautaires sont aussi disponibles.

Des références et variables dynamiques ont été utilisées pour fournir des noms de composants AWS uniques, permettant ainsi le déploiement de plusieurs stages dans chaque région. Pour des raisons de clarté et facilité de maintenance, les composants AWS sont séparés dans plusieurs "templates", d'abord par couches, puis par services si nécessaire. Enfin, j'ai modifié les scripts PowerShell "codebuild" afin de "mapper" correctement les composants AWS déployés dans les "appsettings" extraits de Gitlab.

Sécurisation du réseau du bureau - Vlan, Règles de pare-feu & DOT1X

Mots-clés : Pfsense - Controlleur Wifi - Commutateur (Switch) - Contrôle d'accès au réseau (NAC)Cadre : Travail

Déploiement d'un réseau pour le bureau, avec segmentation et sécurisation via des règles de pare-feu. Un contrôle d'accès au réseau (NAC/DOT1X) a été ajouté pour sécuriser l'accès physique au réseau et placer chaque utilisateur dans le bon segment.

Suite à un déménagement de bureaux, il fut décidé que c'était le meilleur moment pour mettre à jour le réseau en passant d'un simple LAN à un réseau managé utilisant des VLANs. La plupart des employés étant distants dans le monde entier, seuls une vingtaine d'utilisateurs sont au bureau: il a donc été décidé de ne pas trop compliquer les choses. 5 VLANs sont utilisés : USER, ADMIN, VOICE, TEST, GUEST, ce qui est suffisant pour fournir la granularité d'accès au réseau dont nous avons besoin.

Ces VLAN sont pour la plupart explicites. USER regroupera tous les employés à l'exception des administrateurs. Elle disposera d'un accès IPsec basique à nos ressources "CORE" dans AWS. ADMIN est destiné aux périphériques réseau et aux administrateurs. Elle dispose d'un accès IPsec élevé à nos ressources "CORE" dans AWS. Les VLANs restants n'ont pas d'accès IPsec. ADMIN peut accéder à VOICE, TEST, USERS. L'UTILISATEUR peut accéder à TEST. GUEST est isolé. Les règles de pare-feu et tunnel IPsec ont donc été configurées en conséquence dans notre Pfsense.

L'entreprise cherche à passer une certification gouvernementale de cybersécurité: un contrôle d'accès au réseau (NAC) est donc devenu une nécessité. Pour les utilisateurs distants, c'est déjà en place grâce à notre VPN "nomade" avec 3 tunnels (USER, DEV, ADMIN). Afin de se connecter, l'employé utilise ses identifiants AD/O365. Pour le bureau, c'est un peu plus complexe: avoir uniquement des VLANs est insuffisant car il suffit de se brancher sur le bon port pour accéder au VLAN souhaité.

Configurer un contrôle d'accès réseau sur les ports (PNAC) avec DOT1X résoudra ce problème. Dans notre cas, il était plus logique d'utiliser DOT1X plutôt qu'une authentification par adresse MAC. En effet, DOT1X permet aux employés de se connecter au réseau en utilisant leurs identifiants AD/O365. Ces connexions sont envoyées à notre serveur Radius (NPS), qui recherche ensuite si l'employé est un USER ou un ADMIN, puis le serveur Radius répond au périphérique réseau avec le VLAN dans lequel l'employé doit être placé: incroyable !

Migration de région AWS (1/2) - Nouveau VPC, IP Plan & VPN

Mots-clés : Sous-Réseaux - Split-Brain DNS - Route Summary - IPsec & Open VPNCadre : Travail

Planification du réseau pour un nouveau VPC AWS qui hébergera les services "CORE" de l'entreprise. Outre la migration des services "CORE" existants depuis un autre VPC, un serveur VPN avec DNS "split-brain" a été déployé dans ce nouveau VPC.

Pendant de nombreuses années, la société basée en Europe (siège au Royaume-Uni) a utilisé la région AWS IRELANDE (lancée en 2007). À l'époque AWS était encore assez nouveau et ce n'est qu'en 2016 qu'une autre région européenne fut ouverte: LONDRES. Mais à ce moment-là rien ne justifiait une migration de tous les systèmes (coûts, fonctionnalités...). Depuis les choses ont changé avec l'annonce du Brexit et cela a soulevé un certain nombre de questions sur la législation, les risques, les futures orientations concernant la sécurité au Royaume-Uni.

Compte tenu des connaissances et des incertitudes, la décision a été prise de déployer un nouveau VPC dans la région de LONDRES afin que nous y déplacions progressivement nos systèmes "CORE". Le réseau étant construit à partir de zéro, il a été décidé de repenser le plan IP de l'infrastructure de l'entreprise (nouveaux VPC + VPN). Le nouveau plan IP ne doit pas entrer en collision avec les réseaux existants puisque la migration durera un certain temps. 2 blocs IP inutilisés ont été choisis pour les tunnels VPN et le VPC.

Les blocs IP sont divisés en plus petits morceaux avec une logique permettant la récapitulation des routes (route summary), ce qui facilitera la maintenance et l'évolution des configurations des tables de routage et des listes de contrôle d'accès (ACL). Le bloc VPC est d'abord divisé en fonction de l'accessibilité des ressources (privées/publiques) avant d'obtenir les sous-réseaux (DMZ...). Le bloc VPN est divisé afin de mettre en place un accès granulaire (utilisateur, dev, admins) à nos ressources. Les sous-réseaux VPN vont ensuite être mappés aux tunnels VPN.

Un DNS "split-brain" a été mis en place afin de résoudre les ressources avec leurs IP privées lorsqu'on est connecté au réseau de l'entreprise (bureau et VPN). Enfin, j'ai déployé Pritunl, notre nouvelle solution VPN pour les utilisateurs nomades et site-à-site. Il permet de créer des tunnels OpenVPN, Wireguard & IPsec, possède une interface de gestion Web et prend en charge plusieurs sources Single Sign On (O365, SAML, Radius).

Migration de région AWS (2/2) - Amélioration de la gestion du VPC

Mots-clés : ACL / SG - Table de routage - Internet GW & Nat GW - PATCadre : Travail

Refonte de la méthodologie utilisée pour sécuriser les instances AWS EC2. Utilisation de modèles de groupe de sécurité: moins de temps est passé à refaire et à mettre à jour les mêmes configurations. Implémentation des concepts de sous-réseaux publics et privés.

Lors de la planification IP, j'ai préparé des sous-réseaux pour les ressources accessibles uniquement depuis l'intérieur du réseau de l'entreprise (privé) et d'autres pour un accès extérieur (public). Dans AWS, un sous-réseau public est idéal pour des serveurs Web, VPN, ou toute machine généralement placée dans une DMZ. Les sous-réseaux publics disposent d'une passerelle Internet (IGW) et les serveurs (instances EC2) membres peuvent/devraient avoir une adresse IP publique pour pouvoir accéder À Internet et être accédé DEPUIS Internet.

Dans AWS, un sous-réseau privé n'a pas de passerelle Internet et les serveurs membres n'ont pas d'adresses IP publiques: ils ne peuvent donc pas accéder À Internet. Ils ne sont également pas accessibles DEPUIS Internet. Ceci est plus sécurisé car nous ne comptons pas uniquement sur les groupes de sécurité (SG) et listes de contrôle d'accès (ACL). Cependant, si nous ne voulons pas que les serveurs soient accessibles DEPUIS Internet, nous souhaitons qu'ils puissent y accéder. Il y a une différence dans la confiance par rapport à celui qui initie la communication.

Par exemple nous voulons que la machine puisse accéder à Internet pour des mises à jour: pour cela une passerelle NAT doit être ajoutée. Elle effectuera une traduction des IP & Ports (PAT): la box de votre maison fait de même. Cela permet au serveur d'accéder à Internet, tout en les gardant inaccessibles DEPUIS Internet.

Enfin, j'ai proposé une nouvelle façon d'utiliser les Security Group (SG). Une instance EC2 peut avoir jusqu'à 5 SG. Cela permet d'écrire des SG "modèles" par thème. Par exemple, toutes nos EC2 auront leur SG "de service" (qui peut autoriser différents ports), puis on rajoute aussi le SG "gestion" (qui autorise toujours SSH, RDP...). C'est mieux pour la maintenance et la clarté car nous ne réécrivons pas les mêmes choses en permanence. D'autres "modèles" de SG sont utilisés pour l'accès granulaire aux tunnels VPN.

Amélioration du processus d'authentification - AD, NPS et SSSD

Mots-clés : AD Hybride - NPS & Radius - Schéma AD - Joindre un domaine AD - GPOCadre : Travail

Configuration d'un Active Directory (AD) Hybride à partir d'un Azure AD existant, des scripts PowerShell étaient nécessaires. Rechercher comment joindre les systèmes Linux à AD: Découverte, test et déploiement du "démon des services de sécurité système (SSSD)".

Durant un certain temps, l'entreprise n'utilisait qu'Azure Active Directory (AAD) pour la gestion des utilisateurs. L'idée d'avoir un AD local a vu le jour pour l'authentification aux tunnels VPN et aux machines (Windows et Linux). Puisque nous envisagions d'implémenter un AD local (ADDS), il semblait logique de le lier à notre Cloud AD afin de faire un AD Hybride. Mais Microsoft ne permettait pas de passer en mode hybride depuis Azure AD.

Si il est vrai que Microsoft propose un Azure ADDS managé, nous n'avons pas eu le ressenti que c'était la bonne décision. Il n'a pas toutes les fonctionnalités de Local AD (extension de schéma...), des tunnels IPSec seraient nécessaires vers Azure depuis nos bureaux... Il a été décidé de s'en tenir à un AD local. La solution que nous avons trouvée pour avoir un AD hybride consiste à exporter-importer notre configuration Azure AD dans l'AD Local. J'ai écrit des scripts PowerShell qui effectuent l'export-import des utilisateurs et de leurs attributs, afin que nous puissions ensuite lancer la synchronisation hybride sans perdre notre contenu Azure.

Avec notre nouvelle solution VPN, nous avons testé plusieurs options de SSO (O365/SAML...) mais aucune d'entre elles n'a surpassé celle de Radius pour notre cas d'usage. Puisque nous avons maintenant un AD local, j'ai ajouté le rôle NPS. Il s'agit de l'implémentation Microsoft de Radius, avec l'avantage d'être directement lié à AD local et nous pouvons même utiliser le double facteur (MFA) d'Azure (grâce à Hybrid AD).

Enfin, il a été décidé de joindre nos serveurs et clients au domaine afin que les employés puissent se connecter avec leurs propres identifiants. Cette manipulation facile pour les systèmes Windows s'est avéré plus ardue pour Linux. Après quelques recherches, j'ai découvert qu'une distribution Linux assez récente prenait en charge le "System Security Services Daemon" (SSSD) qui permet de joindre un domaine AD. Je l'ai testé pour valider qu'il répondait à nos besoins: connexion des utilisateurs (filtrage GPO), gestion des autorisations (SudoRules à l'aide de l'extension de schéma AD), puis je l'ai déployé.

Environnement de test/bac à sable - Pfsense, GNS3 et KVM

Mots-clé : Simulation et émulation de réseaux - Virtualisation VM & ConteneursCadre : Perso

Création d'un environnement de test (Lab) pour expérimenter et apprendre sur des infrastructures plus réalistes. Le Lab fonctionne avec des solutions Open-Source : Proxmox pour les machines virtuelles et GNS3 pour l'émulation de périphériques réseaux.

Pour acquérir de nouvelles connaissances, j'effectuais des labs sur Cisco Packet Tracer (côté réseau: simulation) et avec des machines virtuelles VMWare (côté système: virtualisation). Cela fonctionnait bien et m'a permis de développer des compétences plus rapidement que prévu, si bien que je me suis retrouvé bloqué. Packet Tracer est limité car il s'agit d'une simulation. Les hyperviseurs (VMWare) ne sont pas conçus pour gérer des réseaux avancés... De plus, j'ai commencé à combiner Réseaux et Systèmes pour apprendre sur des infrastructures plus réalistes.

Pour surmonter ces limitations, dans mon sous-sol, j'ai installé un serveur exécutant l'hyperviseur Proxmox (OS basé sur Linux/Debian). Il offre une interface Web pour gérer les VM (moteur KVM/Qemu). Sur le système Proxmox, j'ai ensuite installé un émulateur réseau (GNS3) qui utilise les véritables systèmes d'exploitation des périphériques réseaux. Les appareils émulés peuvent communiquer en temps réel avec les VM par le biais des vSwitchs Proxmox. J'ai également ajouté un boitier Pfsense avec une VLAN pour accéder aux interfaces de gestion web Proxmox & GNS3. Une autre VLAN (avec un serveur PPPoE) pour mes routeurs GNS3 qui nécessite un accès Internet.

Les conteneurs sont plus légers que les VM et consomment moins de ressources durant mes Labs. Cependant les VM ont toujours leur place, cela dépend du service à exécuter, des compatibilités OS... Proxmox propose les conteneurs Linux. J'ai activé la virtualisation imbriquée (nested) qui me permet de mettre des conteneurs Docker à l'intérieur de ceux de Linux (de cette façon, je peux prendre des 'snapshots' de Docker). Tout ceci augmente ma flexibilité dans mon apprentissage, grâce au Pfsense, je peux même construire une infrastructure hybride expérimentale (AWS, Azure) sans compromettre mon réseau domestique.

Technologies WAN avancées pour la VOIX & DONNEES - MPLS & SD-WAN

Mots clés : SD-WAN - MPLS - VOIP - IPPBX - Service Bureau à Distance (RDS/RDP)Cadre : Etudes

Planification et déploiement d'un réseau étendu (WAN) pour plusieurs succursales. La VOIP était envoyée via MPLS, la communication inter-branches était effectuée via IPsec en utilisant une configuration SD-WAN. Le SD-WAN a également été utilisé pour l'accès Internet dans chaque succursale.

Une importante entreprise mondiale a l'habitude d'acheter des entreprises plus petites dans son domaine: elle vient d'ailleurs d'en acheter une autre plus importante que d'habitude. En raison de toutes ces acquisitions rapides, l'infrastructure informatique du groupe est en désordre: différents logiciels utilisés, pas vraiment d'annuaire d'entreprise, des sites difficiles à interconnecter... La décision de la direction est de repartir de zéro. La DSI du groupe doit fournir un Proof of Concept (PoC) pour une infrastructure orientée collaboration.

Plusieurs choses doivent être faites : plannification IP évolutive, topologie du réseau, quels services déployer... Le choix a été fait d'avoir une infrastructure hybride (Cloud + On-Prem) avec 2 datacenters (DC) dans une situation géographique proche. Une seule forêt hybride AD a été déployée, suivie par Teams et O365 Exchange. Puis les VPN distants et de site à site ont également été configurés. Pour finir un FreeIPPBX (Asterisk) a été ajouté par site pour la VOIX. Les seules choses qui n'étaient pas dans le PoC sont les fermes RDS (bureau distant) dans plusieurs régions AWS pour la proximité des clients légers.

Pour la communication inter-sites, il a été décidé d'utiliser une topologie 'hub & spoke' redondante (via les deux DC). La VOIX est acheminée sur un réseau MPLS pour sa stabilité et sa faible surcharge. Avoir seulement la VOIX ne nécessite pas autant de bande passante et sera donc moins chère. Les DONNÉES sont envoyées via des tunnels IPsec en utilisant des configurations SD-WAN afin de toujours obtenir les meilleures performances en fonction des critères utilisés.

Conception du réseau d'un campus - Redondance et tolérance aux pannes

Mots clés : Etherchannel LACP & PAGP - HRSP - R-STP - Modèles HiérarchiquesCadre : Etudes

Planification et déploiement d'un réseau local (LAN) pour un campus avec quelques bâtiments. Le réseau est segmenté. L'architecture a été pensée pour avoir un réseau redondant/tolérant aux pannes et pour éviter les goulots d'étranglement.

C'était probablement mon premier grand projet réseau. Le contexte était de partir de zéro pour créer réseau LAN d'un campus ce en utilisant une hiérarchie à trois niveaux "Three-Tier Model". Cela devait être fait avec des périphériques Cisco (Dans Packet Tracer). Quelques VLAN étaient nécessaires et en fonction de la taille du bâtiment, un "Router on a Stick" ou un switch avec routage L3 (SVI) serait utilisé. Quelques scénarios d'ACL à implémenter sur les switchs, routeurs et le pare-feu (ASA) ont été donnés.

Il y avait aussi d'autres exigences telles qu'avoir un réseau redondant, sans boucles et avec des agrégations de liens: plusieurs liens ont été utilisés en maillage complet (Full-Mesh) entre les couches CORE et DISTRIBUTION. Les switch L3 ont été configurés avec HSRP sur chaque VLAN (redondance de passerelle), Spanning-Tree a été activé avec Rapid-Spanning-Tree sur les ports d'accès pour raccourcir le temps de connexion des utilisateurs. Enfin, Etherchannel a été utilisé entre le routeur CORE et les commutateurs L3 pour agréger la bande passante et fournir une tolérance aux pannes sur ces liens.

Serveur Minecraft - Amélioration du réseau de serveurs avec un proxy

Mots-clés: Inerprétation de logs - Proxy - Plugin - SessionsCadre : Perso

Déploiement et gestion d'un serveur de jeux, en utilisant un serveur dans mon sous-sol. Avec les nouvelles technologies et les connaissances acquises au fil des années, j'ai graduellement optimisé le serveur pour le rendre plus fiable et améliorer l'expérience utilisateur.

Il y a 8 ans, j'ai construit mon premier serveur Minecraft avec des plugins pour en profiter avec des amis. Avec le temps, j'ai acquis plus de connaissances sur la façon de résoudre mes problèmes en lisant les logs... Étant donné que les plugins sont créés par la communauté, ils ne sont pas toujours mis à jour pour les nouvelles versions de Minecraft: dois-je donc mettre à jour le serveur ? Est-ce que ça va casser les bases de données ? Certains plugins entrent également en collision... Tout cela nécessiterait plusieurs serveurs, ce qui n'est pas bon pour l'expérience des joueurs car ils doivent se connecter/déconnecter manuellement.

À un moment donné, j'ai appris que l'on peut se connecter/déconnecter automatiquement des serveurs (transparent pour les joueurs) à l'aide d'un proxy appelé Bungeecord. J'ai donc monté mon propre réseau de serveurs utilisant un proxy. Cela ma permis de mieux gérer mes ressources car je pouvais désormais arrêter uniquement le serveur sur lequel je devais travailler et non l'ensemble du réseau de serveurs. Je peux aussi utiliser des versions incompatibles (en utilisant des connecteurs de version) et ainsi utiliser tous les plugins que je veux. Malheureusement, j'ai fini par manquer de temps pour continuer ce super projet...

×